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Abstract 


The work related to GMPLS Ethernet Label Switching (GELS) extended 
GMPLS RSVP-TE to support the establishment of Ethernet Label 
Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management 
(CFM) specifies an adjunct Operations, Administration, and 
Maintenance (OAM) flow to check connectivity in Ethernet networks. 
CFM can also be used with Ethernet LSPs for fault detection and 
triggering recovery mechanisms. The ITU-T Y.1731 specification 
builds on CFM and specifies additional OAM mechanisms, including 
Performance Monitoring, for Ethernet networks. This document 
specifies extensions of the GMPLS RSVP-TE protocol to support the 
setup of the associated Ethernet OAM entities of Ethernet LSPs and 
defines the Ethernet technology-specific TLVs based on the GMPLS OAM 
Configuration Framework. This document supports, but does not 
modify, the IEEE and ITU-T OAM mechanisms. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7369. 
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1. Background 


Provider Backbone Bridging - Traffic Engineering (PBB-TE) 
[IEEE.802.10-2011] decouples the Ethernet data and control planes and 
allows external control and management mechanisms to create 


explicitly routed Ethernet connections. In addition, PBB-TE defines 
mechanisms for protection switching of bidirectional Ethernet 
connections. Ethernet Connectivity Fault Management (CFM) defines an 


adjunct connectivity-monitoring OAM flow to check the liveliness of 
Ethernet networks [IEEE.802.10-2011], including the monitoring of 
specific explicitly routed Ethernet connections. The ITU-T 
Recommendation Y.1731 [ITU-T.G.8013-2013] extended CFM and specified 
additional OAM functionality. 


In the IETF, the work related to GMPLS Ethernet Label Switching 
(GELS) extended the GMPLS control plane to support the establishment 
of explicitly routed Ethernet connections [RFC5828] [RFC6060]. We 
refer to GMPLS-established Ethernet connections as "Ethernet LSPs". 
GELS enables the application of MPLS-TE and GMPLS provisioning and 
recovery features in Ethernet networks. 


The use of GMPLS RSVP-TE to support the establishment and 
configuration of OAM entities with LSP signaling is defined in a 
technology-agnostic way in [RFC7260]. The purpose of this document 
is to specify the additional technology-specific OAM entities to 
support Ethernet connections. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Overview of Ethernet OAM Operation 


For the purposes of this document, we only discuss Ethernet OAM 
aspects that are relevant for proactive connectivity monitoring of 
Ethernet LSPs and assume that on-demand OAM functions will be 
supported by management-plane operations. 


PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as a 
provisioned, traffic-engineered, unidirectional connectivity, 
identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where 
the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA 
is the source address of the ESP, and the ESP-VID is a VLAN 
identifier allocated for explicitly routed connections. To form a 
bidirectional PBB-TE connection, two co-routed point-to-point ESPs 
are combined. The combined ESPs must have the same ESP-MAC addresses 
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but may have different ESP-VIDs. The formed co-routed bidirectional 
path is a path where the forward and backward directions follow the 
same route (links and nodes) across the network. 


Note that although it would be possible to use GMPLS to set up a 
single unidirectional ESP, the Ethernet OAM mechanisms are only fully 
functional when bidirectional connections are established with co- 
routed ESPs. Therefore, the scope of this document only covers 
bidirectional point-to-point PBB-TE connections. 


At both ends of the bidirectional point-to-point PBB-TE connection, 
one Maintenance Entity Group End Point (MEP) is configured. The MEPs 
monitoring a PBB-TE connection must be configured with the same 
Maintenance Domain Level (MD Level) and Maintenance Association 
Identifier (MAID). Each MEP has a unique identifier, the MEP ID. 
Besides these identifiers, a MEP monitoring a PBB-TE connection must 
be provisioned with the 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of 
the two ESPs. 


In the case of point-to-point VLAN connections, the connection may be 
identified with a single VLAN or with two VLANs, one for each 
direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, 
MEPs must be provisioned with the proper VLAN identifiers. 


MEPs exchange Connectivity Check Messages (CCMs) periodically with 
fixed intervals. Eight distinct intervals are defined in 
[IEEE.802.10-2011]: 


A A E S E 4+---------------- + 
| # | CCM Interval (CCI) | 3-Bit Encoding | 
+---+-------------------- $ + 
| o | Reserved | 000 

| | | | 
| 1 | 3 1/3 ms | 001 | 
[2] 10 ms | 010 | 
IE | | 
en 100 ms | 011 | 
| | | | 
| 4 | ls | 100 | 
| 5 | 10 s | 101 | 
| | | | 
| 6 | 1 min | 110 | 
o] | | 
| 7 | 10 min | Tri | 
Hato ps ++ E bos He PASAS + 


Table 1: CCM Interval Encoding 
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If three consecutive CCMs are lost, connectivity failure is declared. 
The MEP detecting the failure will signal the defect to the remote 
MEP in the subsequent CCMs it emits by setting the Remote Defect 
Indicator (RDI) bit in the CCM. If a MEP receives a CCM with the RDI 
bit set, it immediately declares failure. The detection of a failure 
may trigger protection switching mechanisms or may be signaled to a 
management system. 


At each transit node, Maintenance Entity Group Intermediate Points 
(MIPs) may be established to help failure localization, e.g., using 
link trace and loopback functions. MIPs need to be provisioned with 
a subset of the MEP identification parameters described above. 


3. GMPLS RSVP-TE Extensions 
3.1. Operation Overview 


To simplify the configuration of connectivity monitoring, the 
associated MEPs should be automatically established when an Ethernet 
LSP is signaled. To monitor an Ethernet LSP, a set of parameters 
must be provided to set up a Maintenance Association and related 
MEPS. Optionally, MIPs may be created at the transit nodes of the 
Ethernet LSP. The LSP Attribute Flags "OAM MEP entities desired" and 
"OAM MIP entities desired", as described in [RFC7260], are used to 
signal that the respective OAM entities must be established. An OAM 
Configuration TLV, as described in [RFC7260], is added to the 
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects specifying that 
Ethernet OAM is to be set up for the LSP. Information specific to 
Ethernet OAM, as described below, is carried in the new Ethernet OAM 
Configuration Sub-TLV (see Section 3.3) within the OAM Configuration 
TLV. 


o A unique MAID must be allocated for the PBB-TE connection, and 
both MEPs must be configured with the same information. The MAID 
consists of an optional Maintenance Domain Name (MD Name) anda 
mandatory Short Maintenance Association Name (Short MA Name). 
Various formatting rules for these names have been defined in 
[IEEE.802.10-2011]. Since this information is also carried in all 
CCMs, the combined length of the MD Name and Short MA Name is 
limited to 44 bytes (see [IEEE.802.10-2011] for the details of the 
message format). How these parameters are determined is out of 
the scope of this document. 


o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely 
identifies a given MEP within a Maintenance Association. That is, 
the combination of MAID and MEP ID must uniquely identify a MEP. 
How the value of the MEP ID is determined is out of the scope of 
this document. 


Takacs, et al. Standards Track [Page 5] 


RFC 7369 GMPLS-Based Ethernet OAM Configuration October 2014 


o The Maintenance Domain Level (MD Level) allows hierarchical 
separation of monitoring entities. [IEEE.802.10-2011] allows 
differentiation of eight levels. How the value of the MD Level is 
determined is out of the scope of this document. Note that 


probably for 


all Ethernet LSPs, a single (default) MD Level will 


be used within a network domain. 


o The desired CCM Interval must be specified by the management 


system based 
CCM Interval 
Ethernet LSP 


on service requirements or operator policy. The same 
must be set in each of the MEPs monitoring a given 
. How the value of the CCM Interval is determined is 


out of the scope of this document. 


o The desired forwarding priority to be set by MEPs for the CCM 
frames may be specified. The same CCM priority must be set in 
each of the MEPs monitoring a given Ethernet LSP. How CCM 
priority is determined is out of the scope of this document. Note 
that the highest priority should be used as the default CCM 


priority. 


o MEPs must be 


aware of their own reachability parameters and those 


of the remote MEP. In the case of bidirectional point-to-point 
PBB-TE connections, this requires that the 3-tuples [ESP-MAC A, 
ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are 
configured in each MEP, where the ESP-MAC A is the same as the 
local MEP’s Media Access Control (MAC) address and ESP-MAC B is 
the same as the remote MEP’s MAC address. The GMPLS Ethernet 
Label format, as defined in [RFC6060], consists of the ESP-MAC DA 


and ESP-VID. 


Hence, the necessary reachability parameters for the 


MEPs can be obtained from the Ethernet Labels (i.e., carried in 
the downstream and upstream labels). In the case of point-to- 
point VLAN connections, MEPs need to be provisioned with the VLAN 
identifiers only, which can be derived similarly from the Ethernet 


Labels. 


Based on the procedures described in [RFC6060] for bidirectional PBB- 


TE Ethernet LSP 


establishment, the Ethernet OAM configuration 


procedures are as follows. 


When the RSVP-T 


E signaling is initiated for the bidirectional 


Ethernet LSP, the local node generates a Path message and: 


o Allocates an 


upstream label formed by combining its MAC address 


(ESP-MAC A) and locally selected VID (ESP-VID1), which will be 
used to receive traffic; 
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o MUST include the OAM Configuration TLV with OAM Type set to 
Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 
objects; 


o MUST include the OAM Function Flags Sub-TLV in the OAM 
Configuration TLV and set the OAM function flags as needed; 


o MUST include an Ethernet OAM Configuration Sub-TLV in the OAM 
Configuration TLV that specifies the CCM Interval and MD Level; 


o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name 
Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, 
which will unambiguously identify a Maintenance Association for 
this specific PBB-TE connection. Note that values for these 
parameters may be derived from the GMPLS LSP identification 
parameters; and 


o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration 
Sub-TLV and select two distinct integer values to identify the 
local and remote MEPs within the Maintenance Association created 
for monitoring of the point-to-point PBB-TE connection. 


Once the remote node receives the Path message, it can use the 
UPSTREAM LABEL to extract the reachability information of the 
initiator. Then, it allocates a Label by selecting a local MAC 
address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive 
traffic. These parameters determine the reachability information of 
the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP- 
VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the 
Ethernet Labels. In addition, the information received in the 
Ethernet OAM Configuration TLV is used to configure the local MEP. 


Once the Resv message successfully arrives to the initiator, this end 
can extract the remote side's reachability information from the Label 
object and therefore has all the information needed to properly 
configure its local MEP. 


3.2. OAM Configuration TLV 
This TLV is specified in [RFC7260] and is used to select which OAM 
technology/method should be used for the LSP. In this document, a 


new OAM Type, Ethernet OAM, is defined. IANA has allocated OAM Type 
1 for Ethernet OAM in the "RSVP-TE OAM Configuration Registry". 
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RSVP-TE OAM Configuration Registry 


OAM Type Description 


1 Ethernet OAM 


When the Ethernet OAM Type is requested, the receiving node should 
look for the corresponding technology-specific Ethernet OAM 
Configuration Sub-TLV. 


3.3. Ethernet OAM Configuration Sub-TLV 


The Ethernet OAM Configuration Sub-TLV (depicted below) is defined 
for configuration parameters specific to Ethernet OAM. The Ethernet 
OAM Configuration Sub-TLV, when used, MUST be carried in the OAM 
Configuration TLV. This new sub-TLV accommodates Ethernet OAM 
information and carries sub-TLVs. 


0 1 2 3 
RA E E E E a O E E PET OS S E a A VIBE 2) 3. EN AS E 
A O O A O O A O hh hh hh ho o o o +++ 
Type 32 | Length | 
A A A O O A O hh hh + o ho +++ 
Version |MD L.| Reserved (set to all 0s) 
A O O O O O A O hh hh hh o o o +++ 
| 


E 


:— + —+— + 


Sub-TLVs 


Type: Indicates a new type, the Ethernet OAM Configuration Sub-TLV. 
IANA has assigned the value 32 from the "OAM Sub-TLVs" space in the 
"RSVP-TE OAM Configuration Registry". 


Length: Indicates the total length of the TLV including padding and 
including the Type and Length fields. 


Version: Identifies the CFM protocol version according to 


[IEEE.802.10-2011]. If a node does not support a specific CFM 
version, an error MUST be generated: "OAM Problem/Unsupported OAM 
Version". 


MD L. (MD Level): Indicates the desired MD Level. Possible values 
are defined according to [IEEE.802.10-2011]. If a node does not 
support a specific MD Level, an error MUST be generated: "OAM 
Problem/Unsupported MD Level". 
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3.3.1. MD Name Sub-TLV 


The optional MD Name Sub-TLV is depicted below. It MAY be used for 
MD naming. 


0 1 2 3 
012345678901234567890123456789021 
E 


| Type (1) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Format | Name Length | Reserved (set to all 0s) | 


+—-+-+-+-4+-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4-4-4-4-4 
K MD Name K 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 1, MD Name Sub-TLV. IANA will maintain an Ethernet TLV Type 
space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV 
types carried in the Ethernet OAM Configuration Sub-TLV. 


Length: Indicates the total length of the TLV, including padding and 
the Type and Length fields. 


Format: According to [IEEE.802.1Q0-2011]. 


Name Length: The length of the MD Name field in bytes. This is 
necessary to allow non-4-byte padded MD Name lengths. 


MD Name: Variable-length field, formatted according to the format 
specified in the Format field. 


If an undefined Format is specified, an error MUST be generated: "OAM 
Problem/Unknown MD Name Format". Also, the combined length of MD 
Name and Short MA Name MUST be less than or equal to 44 bytes. If 
this is violated, an error MUST be generated: "OAM Problem/Name 
Length Problem". Note that it is allowed to have no MD Name; 
therefore, the MD Name Sub-TLV is optional. In this case, the MA 
Name must uniquely identify a Maintenance Association. 
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3.3.2. Short MA Name Sub-TLV 


The Short MA Name Sub-TLV is depicted below. This sub-TLV MUST be 
present in the Ethernet OAM Configuration Sub-TLV. 


0 1 2 3 
012345678901234567890123456789 021 
E 


| Type (2) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Format | Name Length | Reserved (set to all 0s) | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
7 Short MA Name 5 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 2, Short MA Name Sub-TLV. IANA will maintain an Ethernet TLV 
Type space in the "RSVP-TE OAM Configuration Registry" for the sub- 
TLV types carried in the Ethernet OAM Configuration Sub-TLV. 


Length: Indicates the total length of the TLV, including padding and 
the Type and Length fields. 


Format: According to [IEEE.802.10-2011]. 


Name Length: The length of the Short MA Name field in bytes. This is 
necessary to allow non-4-byte padded MA Name lengths. 


Short MA Name: Variable-length field formatted according to the 
format specified in the Format field. 


If an undefined Format is specified, an error MUST be generated: "OAM 
Problem/Unknown MA Name Format". Also, the combined length of MD 
Name and Short MA Name MUST be less than or equal to 44 bytes. If 
this is violated, an error MUST be generated: "OAM Problem/Name 
Length Problem". Note that it is allowed to have no MD Name; in this 
Case, the MA Name MUST uniquely identify a Maintenance Association. 


Takacs, et al. Standards Track [Page 10] 


REC 7369 GMPLS-Based Ethernet OAM Configuration October 2014 


3.3.3. MEP ID Sub-TLV 


The MEP ID Sub-TLV is depicted below. This sub-TLV MUST be present 
in the Ethernet OAM Configuration Sub-TLV. 


0 1 2 3 
012345678901234567890123456789021 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type (3) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Local MEP ID |T|R| Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Remote MEP ID | TĪRI Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 3, MEP ID Sub-TLV. IANA will maintain an Ethernet TLV Type 
space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV 
types carried in the Ethernet OAM Configuration Sub-TLV. 


Length: Indicates the total length of the TLV, including padding and 
the Type and Length fields. 


Local MEP ID: A 16-bit integer value in the range 1-8191 of the MEP 
ID on the initiator side. 


Remote MEP ID: A 16-bit integer value in the range 1-8191 of the MEP 
ID to be set for the MEP established at the receiving side. This 
value is determined by the initiator node. This is possible since a 
new MAID is assigned to each PBB-TE connection, and MEP IDs must be 
only unique within the scope of the MAID. 


Two flags are defined: Transmit (T) and Receive (R). When T is set, 
the corresponding MEP MUST send OAM packets. When R is set, the 
corresponding MEP MUST expect to receive OAM packets. These flags 
are used to configure the role of MEPs. 
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3.3.4. Continuity Check (CC) Sub-TLV 


The Continuity Check (CC) Sub-TLV is depicted below. This sub-TLV 
MUST be present in the Ethernet OAM Configuration Sub-TLV. 


0 1 2 3 
01234567890123456789012345678901 
E 


| Type (4) | Length | 
dh A A O O HHHH 
| Prio | Cœ I | Reserved (set to all 0s) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 4, Continuity Check (CC) Sub-TLV. IANA will maintain an 
Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" 
for the sub-TLV types carried in the Ethernet OAM Configuration Sub- 
TLV. 


Length: Indicates the total length of the TLV, including padding and 
the Type and Length fields. 


Prio: Indicates the priority to be set for CCM frames. In Ethernet, 
3 bits carried in VLAN TAGs identify priority information. Setting 
the priority is optional. If the most significant bit is set to 


zero, the subsequent 3 priority bits will be ignored, and priority 
bits of the Ethernet CCM frame will be set based on default values 
specified in the Ethernet nodes. If the most significant bit is set 
to 1, the subsequent 3 bits will be used to set the priority bits of 
the Ethernet CCM frame. 


CCM I (CCM Interval): MUST be set according to the 3-bit encoding 
[IEEE.802.10-2011] shown in Table 1. As a consequence, the most 
significant bit will be set to 0. Four bits are allocated to support 
the configuration of CCM Intervals that may be specified in the 
future. If a node does not support the requested CCM Interval, an 
error MUST be generated: "OAM Problem/Unsupported CC Interval". 


3.4. Proactive Performance Monitoring 


Ethernet OAM functions for Performance Monitoring (PM) allow 
measurements of different performance parameters including Frame Loss 
Ratio, Frame Delay, and Frame Delay Variation as defined in 
[ITU-T.G.8013-2013]. Only a subset of PM functions are operated in a 
proactive fashion to monitor the performance of the connection 
continuously. Proactive PM supports Fault Management functions by 
providing an indication of decreased service performance and 
therefore may provide triggers to initiate recovery procedures. 
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While on-demand PM functions are, for the purposes of this document, 
always initiated by management commands, for proactive PM, it may be 
desirable to utilize the control plane for configuration and 
activation together with Fault Management functions such as the 
Continuity Check. 


[ITU-T.G.8013-2013] defines dual-ended Loss Measurement as proactive 
OAM for Performance Monitoring and as a PM function applicable to 
Fault Management. For dual-ended Loss Measurement, each MEP 
piggybacks transmitted and received frame counters on CC messages to 
support and synchronize bidirectional Loss Measurements at the MEPs. 
Dual-ended Loss Measurement is supported by setting the Performance 
Monitoring/Loss OAM Function Flag and the Continuity Check Flag in 
the OAM Function Flags Sub-TLV [RFC7260] and configuring the 
Continuity Check functionality by including the Ethernet OAM 
Configuration Sub-TLV. No additional configuration is required for 
this type of Loss Measurement. 


3.5. Summary of Ethernet OAM Configuration Errors 


In addition to the error values specified in [RFC7260], this document 
defines the following values for the "OAM Problem" Error Code. 


o If a node does not support a specific CFM version, an error MUST 
be generated: "OAM Problem/Unsupported OAM Version". 


o If a node does not support a specific MD Level, an error MUST be 
generated: "OAM Problem/Unsupported MD Level". 


o If an undefined MD name format is specified, an error MUST be 
generated: "OAM Problem/Unknown MD Name Format". 


o If an undefined MA name format is specified, an error MUST be 
generated: "OAM Problem/Unknown MA Name Format". 


o The combined length of MD Name and Short MA Name must be less than 
or equal to 44 bytes. If this is violated, an error MUST be 
generated: "OAM Problem/Name Length Problem". 


o If a node does not support the requested CCM Interval, an error 
MUST be generated: "OAM Problem/Unsupported CC Interval". 
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4. IANA Considerations 
4.1. RSVP-TE OAM Configuration Registry 


IANA maintains the "RSVP-TE OAM Configuration Registry". IANA has 
assigned an "OAM Type" from this registry as follows: 


o “Ethernet OAM" has been allocated type 1 from the "OAM Types" sub- 
registry of the "RSVP-TE OAM Configuration Registry". 


o “Ethernet OAM Configuration Sub-TLV" has been allocated type 32 
from the technology-specific range of the "OAM Sub-TLVs" sub- 
registry of the "RSVP-TE OAM Configuration Registry". 


RSVP-TE OAM Configuration Registry 


OAM Types 
OAM Type Number | Description | Reference 
1 | Ethernet OAM | [RFC7369] 


OAM Sub-TLVs 
Sub-TLV Type | Description | Ref. 


32 |Ethernet OAM Configuration Sub-TLV| [RFC7369] 
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4.2. Ethernet Sub-TLVs Sub-Registry 


IANA will maintain an "Ethernet Sub-TLVs Sub-Registry" in the "RSVP- 
TE OAM Configuration Registry" for the sub-TLV types carried in the 
Ethernet OAM Configuration Sub-TLV. This document defines the 
following types. 


Ethernet Sub-TLVs Sub-Registry 


Range | Registration Procedures 

=-= H= === ===> >>> > —- 

0-65534 | IETF Review 

65535 | Experimental 

Sub-TLV Type | Description | Ref. 
0 | Reserved | [RFC7369] 
1 | MD Name Sub-TLV | [RFC7369] 
2 | Short MA Name Sub-TLV | [RFC7369] 
3 | MEP ID Sub-TLV | [RFC7369] 
4 | Continuity Check Sub-TLV | [RFC7369] 
5-65534 Unassigned [RFC7369] 
65535 Reserved for Experimental Use [RFC7369] 


4.3. RSVP Error Code 


IANA maintains an Error Code, "OAM Problem", in the "Error Codes and 
Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource 
Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines 
a set of Error Value sub-codes for the "OAM Problem" Error Code. 

This document defines additional Error Value sub-codes for the "OAM 
Problem" Error Code as summarized below. 


Value | Description | Reference 

ia er eo ee a 
7 | Unsupported OAM Version | [RFC7369] 
8 | Unsupported MD Level | [RFC7369] 
9 | Unknown MD Name Format | [RFC7369] 
10 | Unknown MA Name Format | [RFC7369] 
11 Name Length Problem [RFC7369] 
12 Unsupported CC Interval [RFC7369] 
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6. 


6. 


Security Considerations 


This document does not introduce any additional security issues to 
those discussed in [RFC7260] and [RFC6060]. 


The signaling of OAM-related parameters and the automatic 
establishment of OAM entities based on RSVP-TE messages add a new 
aspect to the security considerations discussed in [RFC3473]. In 
particular, a network element could be overloaded if a remote 
attacker targeted that element by sending frequent periodic messages 
requesting liveliness monitoring of a high number of LSPs. Such an 
attack can efficiently be prevented when mechanisms for message 
integrity and node authentication are deployed. Since the OAM 
configuration extensions rely on the hop-by-hop exchange of exiting 
RSVP-TE messages, procedures specified for RSVP message security in 
[RFC2747] can be used to mitigate possible attacks. 


For a more comprehensive discussion of GMPLS security and attack 
mitigation techniques, please see "Security Framework for MPLS and 
GMPLS Networks" [RFC5920]. 
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